In general, UMTS is a third generation mobile communications system that has evolved from GSM (Global System for Mobile communication), the standard in Europe. The UMTS provides a variety of services by combining radio access networks with WCDMA (Wideband Code Division Multiple Access) techniques based on GSM. The UMTS standard is being developed by a standards organization called as 3GPP (3rd Generation Partnership Project). 3GPP proposes a standard including therein more improved functions with a progress of development stages, where the development stages for standardization are classified by release numbers.
FIG. 1 is a block diagram schematically illustrating UMTS to which the present invention is applied.
Referring to FIG. 1, reference numeral 10 indicates a core network, reference numeral 20 indicates a UTRAN (UMTS Terrestrial Radio Access Network), reference numeral 30 represents an RNS (Radio Network Subsystem), reference numeral 31 refers to an RNC (Radio Network Controller), reference numeral 32 indicates a Node B (base station), and reference numeral 40 represents a UE (User Equipment).
In general, UMTS includes the core network 10, the UTRAN 20 and the UE 40, where the core network 10 has all network elements relating to subscriber call control, session management, mobility management, intra-network switching and the like. The network elements of the core network 10 can be classified into nodes belonging to a circuit-switched area, a packet-switched area, and a register area. The circuit-switched area includes an MSC/VLR (Mobile Switching Center/Visitor Location Resister) and a GMSC (Gateway Mobile Switching Center), which can be physically located in the same apparatus. The MSC/VLR controls circuit-switched connection; performs mobility management such as location update, location registration and paging; and secures data. The GMSC plays a role as a gateway connecting the circuit-switched area to an external network.
The UTRAN 20 is connected to three domains of the core network 10. That is, it is connected to a circuit-switched domain for circuit switching, to a packet switched domain for packet switching, and to a broadcasting domain for a broadcasting service.
The RNC 31 in the UTRAN 20 controls elements of the RNS 30 to dynamically allocate wireless resources of the UTRAN 20. Further, it performs a switching function for transferring data received from the UTRAN 20 to suitable nodes. Since the RNC 31 is directly connected to the core network 10, it serves as a service access point for all the services provided by the core network 10.
The Node B 32 functions as a physical layer in UTRAN 20, and transmits and receives data over an air interface. The Node B 32 sets wireless physical channels for use in exchanging data with the UE 40 based on control information received from the RNC 31, converts data received from an upper layer thereof to have a suitable form for the wireless environment and transmits it to the UE 40. Further, the Node B 32 transmits data received from the UE 40 to the upper layer.
The UE 40 is provided with a USIM (UTMS Subscriber Identity Module) card. Since the USIM card storing therein information on the user identity is detachable from the UE 40, a standard interface between the USIM card and the UE 40, which is called “Cu” interface, is defined. Herein, the concept of the USIM card might not be clear, but the USIM card can be physically implemented in the form of an IC (Integrated Circuit) card and include various applications or several USIM functions.
Further, a BCH PDU generation function of UMTS performed using a system information update procedure between the RNC 31 and the Node B 32 and BCH scheduling information within the Node B 32 preferably meets 3GPP specification requirements (3GPP TS 255.433 UTRAN Iub interface NBAP signaling and 3GPP TS 25.331 Radio Resource Control (RRC) protocol specification). Further, a success of performing the above-described process without an error on a BCH PDU length depends on whether a scheduling algorithm of the RNC 31 has a method for detecting an error on the BCH PDU length and the Node B 32 can immediately detect an error.
The system information update procedure performs operations required for the Node B 32 to accurately schedule system information segments on the BCH. This procedure is initiated when a CRNC (Controlling RNC) transmits a system information update request message to the Node B 32. At that time, the Node B 32 needs to update MIB (Master Information Block), SB (Scheduling Block) and SIB (System Information Block) information included in the system information update request message to the BCH schedule.
In UMTS, before data is broadcasted to the UE 40 via the RNC 31 and the Node B 32, (1) system information update procedure, (2) system information BCH PDU generation procedure, and (3) system information BCH PDU transmission procedure are performed, which will be described in sequence.
(1) System Information Update Procedure (See, 3GPP TS25.433 UTRAN Iub Interface NBAP Signaling)
This procedure is initiated with a system information update request message sent from the RNC 31. The system information includes one MIB segment, two SB segments and 27 SIB segments.
This message includes segment information (i.e., types and lengths of the MIB, SB and SIB segments) and scheduling information (i.e., IB_SG_REP and IB_SG_POS) indicating a transmission start time of each segment.
The Node B 32 sends a system information update response message to the RNC 31 to indicate success if a physical channel scheduling cycle can be updated using parameters included in the system information update request message. Otherwise, the Node B 32 sends a system information update failure message to the RNC 31 to thereby indicate failure.
(2) System Information BCH PDU Generation (See, 3GPP TS 25.331 Radio Resource Control (RRC) Protocol)
The Node B 32 combines information of the segmented system information blocks received in the system information update procedure and then, attaches thereto header information such as an SFN (System Frame Number), a combination type and a segment length. Thereafter, the Node B performs the ASN.1 (Abstract Syntax Notation One) encoding, thereby generating a system information BCH PDU of 246 bits to be transmitted to the UE 40.
The segments can be classified into four types: First segment, Subsequent segment, Last segment, and Complete.
The Node B 32 generates the system information BCH PDU by combining one or more segments having various lengths, where the system information BCH PDU can be defined as one of eleven combination types: No segment; First segment; Subsequent segment; Last segment; Last segment+First segment; Last segment+one or several Complete; Last segment+one or several Complete+First segment; one or several Complete; one or several Complete+First segment; one Complete of size 215 to 226; and Last segment of size 215 to 222.
(3) System Information BCH PDU Transmission (See, 3GPP TS 25.331 Radio Resource Control (RRC) Protocol)
The Node B 32 sends the system information RRC PDU to the UE 40 at every 20 ms over a PCCPCH (Primary Common Control Physical Channel), the system information RRC PDU being generated according to the scheduling information (IB_SG_REP, IB_SG_POS and SEG_COUNT) indicating the transmission start time of each segment received in the system information update procedure. Here, the transmission start time (i.e., SFN) is expressed as:SFN mod IB_SEG_REP=IB_SEG_POS(i), i=0, 1, 2, . . . , SEG_COUNT−1.
At this time, each segment is scheduled with a specific repetition rate and a specific position based on the IB_SEG_REP and IB_SEG_POS values, and further different segments combined together can occur at a specific SFN.
When the RNC 31 transmits wrong scheduling information via a system information update request message to the Node B 32 during the system information update procedure in UMTS, if the Node B 32 cannot detect an error on the system information BCH PDU before performing the ASN.1 encoding, wrong system information can be transmitted to the UE 40. Furthermore, if an error is not immediately detected, the UE 40 can be placed out of service, thereby reducing reliability of the overall system. Therefore, the Node B 32 needs to be able to detect a scheduling information error and report the error to the CRNC.
Further, in order to generate the BCH PDU efficiently for every SFN ranging from 0 to 4094 and transmit the generated BCH PDU to the UE 40, a method for representing BCH PDU status information of each SFN using the minimum amount of information is necessary. However, such a method has not been available.